「ECS Best Practice All on board」というタイトルでJAWS PANKRATION 2024に登壇しました #jawspankration2024 #jawspankration #jawsug
2024.08.26はじめに
お疲れさまです。とーちです。
2024/8/24~8/25にかけて開催された「JAWS PANKRATION 2024」で登壇しました。
本記事ではその際に使用した資料をご紹介します。
登壇資料
登壇した際に使用した資料です。
日本語に翻訳した資料も置いておきます。機械的に翻訳したので、妙な日本語になってる部分があります。
資料概要
ECSベストプラクティスとは
AWSはECSのベストプラクティスとして以下のドキュメントを公開しています。
Amazon ECS のベストプラクティス - Amazon Elastic Container Service
今回の資料では上記のドキュメントや上記ドキュメント等を元に独自にまとめたチェックリスト等をベストプラクティスと定義し、その中で実際に実装する際に悩みやすいポイントについて解説しています。
CI/CD
ベストプラクティスとしては、インフラ、アプリケーション双方でCI/CDパイプライン等で変更を自動化することにより新規作成や更新の信頼性を高めましょうということになります
IaC
インフラのCI/CDを考える際には当然ですがまずIaC言語として何を使用するかを決める必要があると思います。
ベースとして使用するIaCとしてはTerraformかCDKのどちらかであれば間違いないと思いますが、ECSならではの考慮点としてタスク定義やECSサービス設定をどこで管理するかという問題があります。
この資料ではタスク定義やECSサービス設定を管理するためのツールとしてecspressoを紹介しています。
ecspressoはTerraformやCloudFormationと連携できるので、既存IaCとの連携もしやすいです。
以下はecspressoで使用するECSタスク定義の例です。TerraformのtfstateファイルからCloudWatchLogsのロググループのARNを参照しているのがわかるかと思います。
ブランチ戦略
インフラとアプリケーションの観点でブランチ戦略を絡めた具体的なパイプラインフローについて検討し記載してみました。
アプリケーションの方については私があまりその分野に明るくないので、想像で書いている部分があるのでご了承ください。
タスク定義
タスク定義については、タスクのサイジングとコンテナイメージを作るためのDockerfileの書き方について説明しました。
タスクのサイジング
パフォーマンステストを行いCPU使用率、メモリ使用率を確認して調整するのが基本になるかと思います。
コンテナ毎のCPU,メモリ使用率についてはCloudWatch Logs Insightsで以下のクエリを実行するのがお手軽です。
fields @timestamp, CpuUtilized, CpuReserved, CpuUtilized * 100 / CpuReserved as CpuUtilization,
MemoryUtilized, MemoryReserved, MemoryUtilized * 100 / MemoryReserved as MemoryUtilization
| filter ContainerName = "xxxxx" and Type = "Container" and TaskId = "yyyyy"
| sort @timestamp asc
| limit 10000
| stats avg(CpuUtilization),avg(MemoryUtilization) by bin(1m)
また、タスク定義の中で指定するCPU,メモリの設定の詳細な意味合いについても説明しています。
Dockerfileの書き方
Dockerfileのベストプラクティスは既に多くの方がご存知だと思いますが、私自身最近知ったベストプラクティスと呼べる書き方がいくつかあったのでそれをご紹介しています。
コンテナセキュリティ
ベストプラクティスとしてはコンテナのライフサイクルに沿ってセキュリティ対策を行う、ということになります。
セッションではコンテナイメージレジストリの対策とコンテナランタイムセキュリティについて触れました。
ランタイムセキュリティ
ランタイムセキュリティとは実行中のコンテナに対する脅威に対する仕組みを指しています。
GuardDuty RuntimeSecurityについての説明とSaaSのセキュリティ製品の違いについて、簡単にご紹介しています。
オブザーバビリティ
オブザーバビリティの概念も世間一般に知られてきていると思います。ここではトレースについてお話しています。
トレース
AWSでトレースといえば自分の認識だとX-Rayだったんですが、少し前からAWS Distro for OpenTelemetry(ADOT)というものが登場してきています。
ADOTとはAWSがサポートするOpenTelemetryディストリビューションなんですが、従来X-rayならX-ray用SDK、CloudwatchならCloudwatch用のSDKとオブザーバビリティツールごとに用意していたSDKなんですが、OpenTelemetryではSDKとCollectorに分けることで、様々なオブザーバビリティツール向けのデータ送信を共通のSDKで実装できるのが特徴になってます。
感想
実は初のJAWS登壇でした。昔からJAWSで登壇することに憧れていたので、今回登壇出来て感無量でした。
かなり準備したのですが、それでも自分の知識が足りていない部分や、実際の登壇時に尺が足りずに最後駆け足になったりと１００点満点と呼べる登壇ではありませんでしたが、登壇の準備を通して自分自身の知識のアップデートも出来たので良かったです。
次回登壇する際はもっと良い登壇にできればと思います。
この記事が誰かのお役に立てばなによりです。
以上、とーちでした。
参考にさせて頂いた記事・サイト
- Amazon ECS best practices - Amazon Elastic Container Service
- ECSのローリングアップデートとブルー/グリーンデプロイを比較してみた | DevelopersIO
- Amazon ECS タスク定義の"タスクサイズのCPU"と”コンテナのCPUユニット”の違いを調べてみた - のぴぴのメモ
- How Amazon ECS manages CPU and memory resources | Containers
- AWS ECS コンテナ毎のメトリクスを取得する #CloudWatch - Qiita
- phamthanhgiang/ECS-Fargate-hands-on
- Dockerfile を書くベストプラクティス — Docker-docs-ja 24.0 ドキュメント
- トレース｜OpenTelemetry入門
- 2024年版のDockerfileの考え方＆書き方 | フューチャー技術ブログ
![[レポート] Optimize data processing with built-in AWS Step Functions featuresに参加しました #AWSreInvent #API207](https://images.ctfassets.net/ct0aopd36mqt/3IQLlbdUkRvu7Q2LupRW2o/edff8982184ea7cc2d5efa2ddd2915f5/reinvent-2024-sessionreport-jp.jpg)
